在我心目中, Flickr 才是第一個透過 "群眾智慧" 成功的案例, 且現在還是蠻可以運作的一套系統, 當歐萊禮的 Building Scalable Web Sites 出來之後, High Availbility 慢慢的被一些行銷與經營的人接受, 但高有效性的技術對大部份的程式設計師還是一個相當陌生的領域.
但規模化的須求本來就是在一個足夠大的網站才須要去管的, 只是當這網站足夠大的時候, 就是一間不算小的公司在維運, 也就是說並不是 IT 的人都會接觸到 Scalable 規模化的概念與議題, 到最後寫出來的程式還是很接近慘不忍睹.

的確規模化最大的問題在於成本與限制, 任何系統都有其限制, 這限制來自於技術, 以及其收益背後所導致的成本限制, 只是大部份的限制都可以被成本給解決掉, 只有最關鍵的問題是沒辦法被解決的, 這就是瓶頸.

通常的瓶頸是來自於一台機器或一組機器, 一個機制或是一個環節, 例如同步的效率, 資料規模造成的效率瓶頸, 最大的使用者量, 等等的問題, 但通常絕大部份的問題都可以被解決, 只是往往要犧牲一些東西, 這些東西可能是一致性, 也可能是效率, 最有可能的是成本.

沒有東西可以無限制的被追求而沒有產生新的問題, 只是這新的問題能不能被控制, 或可被接受, 就像是當人一多, 要在一定時間內反應, 就只好付出非同步的代價, 通常這在社群網站是可被接受的, 但電子商務網站不行, 但幸而交易平台的成本通常可以被拉很高, 或者是可以被切割出來後量也不會像 UGC (Users Generated Contents) 那樣的大量.

當然在現在而言, 有太多的技術能夠把這問題解決大部份, 例如 AJAX, NoSQL, REST, node.js, Cloud Computing, CDN, 等等, 甚至有些問題是可以去 Out Sourcing 委外的, 這對 HA 設計者是值得慶幸的, 但一個好的與壞的 HA 規劃師的差別不只是結果的好壞, 成本的差距是可以拉到好幾倍的狀況.

事實上規模化有很多層級:

1. 程式邏輯層級
2. 資料庫使用層級
3. 系統分析層級
4. 硬體與作業系統層級
5. 網路層級
6. 使用者操作與介面層級

當然往下與往上還可以細分與 Refinement, 例如資料庫可以從管理與指令的下法去規模化, 更上面是管理者的觀點都有會影響如何去做規模化, 例如可以不開放這項功能與否那樣.

但說穿了, 規模化最重要的技巧就是找到瓶頸, 一個個拆解與找到方法解決, 而這個就跟效能調校有很大的關係,這個後面會說, 而在效能調校之前, 就是要去好好的監控每一個資源的使用方式, 所以高有效性真的是環環相扣阿.

而規模化也是有專書與專門的課程在上, 要靠一兩千字只能做在高有效性做前提而已, 所以最後還是要去靠大家去唸與學習, 畢竟魔鬼是在細節.